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The invention is described in the following statement: 



SYSTEM FOR ORDERING, TRACKING AND PAYMENT OF GOODS AND 
SERVICES PROCURED FROM NUMEROUS SOURCES. 



FIELD OF THE INVENTION 

This invention relates to the facilitation of computer-based electronic 
commerce and the application of electronic commerce in improving business 
efficiencies and solving business problems across several industries. 



SUMMARY 

The invention is a computer based means of managing and controlling the 
execution or performance and payment of multiple undocumented supply 
contracts from a small closed group of individuals or entities procuring from a 
numerous but closed group of suppliers where the general commodity traded 
is traded in high numbers with a low number procured from each supplier. 

The system manages the following components of the contract including: 
request, allocation, communication to supplier, response by supplier, proof of 
performance by supplier, payment of supplier, reporting, reporting to third 
parties. The system automates a significant portion of the communication 
between parties during the process. 



THE INVENTION 



In particular, our system facilitates commerce where a numerous set of 
suppliers provide a similar product or service to a limited group of purchasers. 
It does this by managing supply electronically. 

It also facilitates commerce where it is seen as impossible to oblige suppliers 
to adopt electronic methods for communication but where electronic 
management is desirable. It does this through the document processing 
centre. 



It has another addition in reducing the moral hazard of situations where the 
ordering party in a transaction is not the paying party such as insurance 
repairs. It does this through reporting. 

Our solution solves problems where a concentration of groups eg. Life 
Insurers, Employment Agencies needs to attract responses or manage 
execution or delivery from a wide range of entities such as Medical 
Practitioners, individual referees, temps or otherwise. We have identified 
multiple other potential usages. 

In general this is useful where the supplying party is outside the usual 
communications scope of the requiring organisations. This can include casual 
staff workforces, those who spend a significant or all of their time in the field, 
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those working from home, locum staff, freelance staff. Such individuals or 
parties may not have organisational e-mail addresses, may not be on a 
payroll and may not visit the office. 

For instance, casual airline cabin crew may only be 'on-cair and may 
therefore only appear to work at an airport. They may not have a work e-mail 
address and their time in an office is limited to entry and exit through the 
airport on the way to an from an aircraft. In these instances, work 
management may currently be through timesheets that must be collated by 
the organisation from each and every aircraft involving enormous 
organisational complexities, particularly when air routes do not pass near 
major hubs. For instance, a hostess or steward who works casually between 
Mildura and Dubbo may never visit headquarters and their timesheets have to 
change aircraft in Dubbo to Sydney and from their be transferred to the payroll 
department In our solution, the onus will be on the member of the cabin crew 
to gain a signature on their timesheet and forward it themselves to the 
organisation through any of the agreed means. A similar scenario applies to 
temporary staff. 

It is useful where the determinant of supplier is most usually not price - a 
factor that differentiates our invention from online or reverse auctions. For 
instance, the drivers can be geography, expertise, random, individual turn 
taking, indeed even physical appearance in the case of a modelling or acting 
agency. It is also helpful where the price is either pre-determined or 
commoditised such as a price per word for journalists, a pre-agreed rate for 
models, a standard price per km for couriers or otherwise. 

Perhaps the closest prior art to our invention is the modem computer system 
in taxis. The determinant of the supplier is physical location of the cab, and 
the price is fixed. However, the job allocation system neither allocates nor 
measures or manages revenue or trade between the assigning organisation 
and the driver. In addition, this is a solution particular to the taxi industry that 
involves entry costs in the form of computer purchase or rental. Our system is 
designed to eliminate entry costs for participating in a trading field by 
genericizing response media and using everyday accepted communication 
media available to the public. 

DIFFERENCES FROM SIMILAR PRIOR ART 

Our system differs from online auction systems, because in our system, the 
suppliers are a known and closed group who are not competitively bidding for 
supply rather than an unknown and open group competing against each 
other. Our system is appropriately used when the supplier of a good or 
service is already determined, and the administration of that trade is difficult to 
manage due to the numerous suppliers. 

It also differs in its application - our invention is designed to improve and 
accelerate process with a secondary goal of cost reduction through 
efficiencies and standardisation. 
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In particular, the distinguishing features of our invention include: third party 
web hosting options, variable payments, online generation of relevant tax 
invoices, capture of supplier details for further communication, reporting for 
relationship management, guaranteed immediate payment, all the features 
associated with the document processing centre, homogenisation of response 
media into electronic format, the industry wide solution, first time letters and 
others. 

We are aware that in the UK a study was undertaken by a medical software 
expert to look at ways of communicating between Medical Practitioners and 
the Life Insurance industry. This has not been implemented, and we were 
unable to gain access to the private recommendations. Extensive searching of 
the internet revealed no document, only references to a study. We inquired of 
the consultants and were referred to the relevant government health 
department. We do believe, however, that the study focussed on a very 
unilateral imposition of a single system based on the UK National Health 
System Data Communication network. Our solution is different to this in that 
we are not imposing a solution unilaterally as will be displayed further on in 
this document. In addition, our offering is currently being turned into a live 
offenng by our contracted software developer. To the best of our knowledge, 
and according to the information provided by the UK consultants, no such 
system has been put into functionality. 

APPLICATIONS OF INVENTION 

We have provided four sample flowcharts for potential operation of the 
system. However, we have also envisaged the following uses for the system: 

1 . Life Insurance Pathology Requirements 

2. Life Insurance Medical Practitioner Report requirements 

3. Employment Agency and Employer reference checks 

4. Corporate surveys presented to individuals. 

5. Market research including media ratings 

6. Distribution of small person contractor work, such as translation 
couriers, home visits or other work. 

7. The management of home based workers. 

8. Purchase of agricultural product from small suppliers. 

9. General Insurance Repair Requests eg. When an insurer requests a 
smash repairer local to their insured party to undertake work at their 
expense. 

1 0. Modelling/Acting agencies 

1 1 . Field Staff Management eg. sales visits 

12. Locum Staff Management eg. GPs. 

13. Air Cabin Crew 

14. Freelance Journalists 

1 5. Temporary Staff management for an agency. 
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BACKGROUND TO INVENTORS 

Matthew Mulcahy has been at the Life Insurance Company AMP for around 
fifteen years and in that time has experienced multiple commercial and 
financial roles, including as the Finance Relationship Manager and the 
Outsource Manager for the Customer Service Division. He has extensive 
expertise in the field of reporting and financial management. 

Seb Mackinnon graduated in Economics and Politics from Bristol University in 
the UK and has worked in the mining and financial services industries in 
project management, procurement and IT management roles. He currently 
works alongside Matthew Mulcahy in the Customer Service Commercial 
Team as a Commercial Contract and Relationship Manager. 
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BACKGROUND TO INVENTION 

The invention arises from difficulties experienced by the inventors in solving 
business problems at their workplace. The inventors worked at a company 
that amongst other services offers Life Insurance. The Life Insurance industry 
across many countries faces problems with the PMAR process. That is the 
process where a Life Insurer must write to the medical practitioner treating the 
applicant to receive further information for the purposes of underwriting. 
Previous efforts at our own employer to improve the situation had failed. 

The time taken and the costs of processing these requests for information is 
significant as the Life Insurance Organisation has to write to thousands of 
Medical Practitioners a month, await individual invoices prior to payment to 
avoid withholding tax and then pay those invoices on receipt of the 
information. In particular, delays by individual Medical Practitioners cause 
their patients (life insurance applicants) to cancel their Life Insurance 
applications. Medical Practitioners reportedly place a low priority on "well 
patients' and would also be more profitable giving patient consultations. We 
believe similar problems exist in other industries where there is significant 
reliance on an individual to supply. 

At the time of writing this document, this PMAR process remains a significant 
time consumer in Life Insurance Organisations. Medical practitioners have 
little or no incentive to undertake the tests quickly. Their speed of response is 
slow. Their bills vary from provider to provider. At the minimum there is a two 
to four day postal cycle as Medical Practitioners would not opt into a fully 
electronic system to justify its creation by one single company. 

There is also moral hazard present where the authority to procure on behalf of 
a firm is delegated to third parties (in this case financial planners) with limited 
responsibility for the associated costs. Whilst this hazard cannot be 
eliminated, we believe that it can be controlled by availability of reporting. This 
reporting becomes very cost-effective under an automated system. 

We therefore developed this solution to solve these specific problems and 
other similar problems in various industries. We were aware that the solution 
would be best applied industry wide and so developed the portal concept. 

We quickly understood a range of other applications that the combination of a 
web hosted e-commerce facility combined with a document processing centre 
could offer in situations where the determinant of supplier is not price, and 
where the suppliers are multiple and outside the usual communications scope 
of the purchaser. 

The other major impact solution we devised is one for managing temporary 
staff. This is a solution for managing temporary staff and is principally aimed 
at employment agencies. However, a company could simply manage temps 
directly or as a third party with a temp agency being responsible for payment 
to the individual and on-billing to the ultimate employer. 
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The system would provide reporting to allow on-billing. Work requirements for 
certain hours could be created and processed through the hub out to the 
individual by their preferred communications medium. 

Once the temp had completed their work hours, the responsibility would fall 
on them to ensure that their timesheet was uploaded. They would have the 
choice to enter it electronically online for quicker payment, or could send it for 
normal upload. The authority from their ultimate employer would normally be 
prior to submission. The Document Processing Facility could OCR a normal 
timesheet and upload it to the correct individual's record (the correct set of 
purchase orders for hours). This would be visible to the requestor inside the 
organisation utilising the services of the temp, and they, or the agency could 
authorise payment at this late stage if required. 

Otherwise, payment could be automatic but this would be subject to fraud 
risks and would need to be monitored. Monitoring would be possible with the 
reporting generated by the tool. 

Reporting would be available: timesheets would be homogenised without 
obliging staff to utilise any technology they do not wish to or which is not 
currently normal practice, reporting would be available and the admin involved 
in temp management would be significantly reduced. 

No such employment system exists, which is one reason that employers are 
forced to use expensive temp staff agencies rather than manage contractors 
themselves. To date, no system exists that homogenises proof of supply or 
information fulfilment to avoid obliging suppliers to uptake technology. 

The system has usages directly for employment agencies as a management 
tool; and also for corporates managing contractor workforces. Obviously, the 
solution is only applicable to large corporates where they undertake the 
recruitment themselves. 
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THE PROBLEM 
The particular needs we identified were: 

- Centralised request mechanism that encompasses multiple requestors 
and multiple providers across and industry. 

- Centralised billing mechanism that consolidates multiple supplier bills and 
links them into requests. 

- Automated billing mechanism to reduce workload of bill payment. 

- Automated billing mechanism linked to fulfilment of contract. 

- Automated billing mechanism to reduce processing costs for requestors. 

- Automated payment trigger system to facilitate credibility and guarantees 
for suppliers. 

- Automated variable performance related payment system to incentivize 
respondents. 

- Opportunity for providers to generate appropriate invoices without 
turnaround times of invoicing and remittance. 

- Electronic communication method to reduce postal turnaround times in 
terms of request submission and response submission. 

- Method to facilitate old technology responses eg. fax and post including 
partially homogenised presentation to requestors and similar payment 
systems. 

- Facility to pay on creation of report. 

- Facility for providers to view all of their outstanding requests and for 
requestors to review their outstandings. 

- Facility for interested third parties to view outstanding requests relating to 
them. 

- Opportunity to feed back results from other corporate third parties into the 
same system. 

- Centralised request register with statistical reporting to allow management 
of key respondent relationships. 

- Need to interact with parties outside organisational communications scope 
eg. Not on company e-mail, circulation lists, not normally in the office. 

- Need for detailed transaction reporting to control moral hazard. 
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UNOBVIOUSNESS 

'PMARs have been a problem for twenty years. We don't see a way to fix 
them right away, and they could stay a problem for twenty years.' 

These words were used in conversation with one of the inventors by a person 
responsible for that particular component of a Life Insurance Organisation's 
process. 

Inside the life insurance industry, this problem is frequently discussed and the 
most significant move to improve the problem was merely agreeing a 
schedule of fees between Life Insurance Companies and the Australian 
Medical Association, to which most medical practitioners do not adhere. 

We have seen how the situation remains a problem in the life insurance 
industry today despite: 

A study one to two years ago by UK consultants 

Significant efforts across Australian Life Insurance companies 

Focussed attention in the industry 

A comfortable four years of high internet uptake. . 



In one Life Insurance Organisation the inventors know, staff have spoken in 
very general terms about using our future scanning and imaging systems 
across this area. However, they have missed the fundamental point, which is 
that medical practitioners require an industry wide solution and they require 
multiple submission methods. 

We believe we can through the combination of multiple technologies. 

We have also found synergies in our service. We started off with the concept 
of using the invention to speed communication in one-to-many purchasing 
relationships. We then came upon the concept of automated payments, then 
the concept of guaranteed payments, then variable payments to incentivise 
suppliers that are managed automatically. 

One feature of unobviousness is the fact that our invention solves problems 
addressing multiple industries without being dependent on any adoptation of 
new technology or principles by the suppliers involved. Whilst the need for 
communication between Medical Practitioners and the Life Insurance industry 
has been discussed and documented, no solution of which we are aware has 
ever been so easily deployable and allowed late adopters to continue to use 
old technologies or had any of our value adds such as triggered payment or 
service bonuses in payment. PMAR reports have been a perennial problem 
for the Life Insurance industry and remained unsolved until our invention. In 
particular, technology innovators, and e-commerce experts assigned to 
deliver a solution have not devised this invention. 
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In prior art, this solution would not have been visible on its own: scanning 
does not lead to this solution without e-commerce or without industry wide 
solutions and nor does it offer multiple channels of communication on its own. 
To combine the prior arts of e-commerce, scanning, multiple communication 
channels, web database hosting required multiple stages in our thinking. The 
potential for guaranteed payments is an unforeseen advantage, and we 
believe we have also identified and solved an unrecognised problem in the 
recruitment industry. Over recent years, service speed expectations have 
improved to the point where the 'reference phase' of a recruitment process 
remains a significant barrier to achieving quick results without sacrificing 
quality and using telephone references etc. Our solution allows the industry to 
reinstate the old quality of written results and still match current speed 
expectations. 

Our commercial models show this to be a commercially viable opportunity, 
particularly when deployed across wider industries. That is why we have 
proceeded to patent phase. 
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DRAWINGS 

Seven drawings are attached: 

Fig 1 . System interaction flowchart 
Fig 2. Sample process for PMAR 
Fig 3. Sample process for paramedical and pathology 
Fig 4. Sample process for employment reference. 
Fig 5. Sample database scheme 

Fig 6. Sample process for temporary/contractor staff management 
Fig 7. Sample Screens for combined paramedical/PMAR solution. 
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DETAIL SOLUTION 

At the heart of the solution lies a web, internet and database based request 
and response processing, presentation and payment hub. 

The first and most fundamental step is the creation of the root database. This 
database system will manage all of the requests/orders and fulfilments. 
Multiple schemas may be required within the central server assembly to 
handle different types of request, but the generic solution remains the same 
as shown in figure 1. The database is called the Hub in the diagram. 

The root database must have a web and internet enabled front end to allow 
access and administration by authorised parties. 

In one form of our system, all requests are generated on to the hub through 
the internet. Multiple interfaces can be created to be company specific, and to 
allow varying levels of ownership and security. 

In Figure 1, the bold lines indicate interaction with the hub, whereas the 
narrow lines do not involve interaction with the hub. 

In the diagram, a request or order may be processed onto the system by any 
of the following parties: Intermediaries or third parties authorised by the 
system subscriber such as financial planners, sub-contractors etc. These 
requests are shown by R4 and R5. A final consumer is not shown creating 
orders in Figure 1 , but this is possible. For now, we have shown li , r2, r5 and 
r4 as not involving interaction. They display that a consumer may contact the 
system subscriber directly or indirectly. Although the requests may come from 
parties requesting through different system subscriber accounts (eg 
Consumer 2 is through Corporate Entity A whereas Consumer 4 is through 
Corporate Entity b), the requests may exist within the same database schema 
and be differentiated at the later stage by, for example, the template on the 
communication to the respondent, or through the interface presented to the 
requesting party. Indeed, some intermediaries may generate requests through 
different interfaces on behalf of different system subscribers, but those 
requests may exist in the same database and may indeed be viewed through 
a single interface. 

The system subscriber, normally a corporate entity as shown by Corporate 
Entity A or Corporate Entity B can set up their own internal chains of 
command and access routing and regulations. In Figure 1, we have shown 
system subscribers (Corporate Entity) comprising two teams each (Teams 
A&B and Teams C&D). Within those teams are Persons A-H. The corporate 
may choose to have additional levels or responsibility, visibility and 
ownership. The requesting entity may enter the details of the supplier and 
also create visibility and tracking rules for other third parties such as 
Consumer 1 whose visibility is indicated by V1. The requesting entity should 
create visibility rules and assign access controls to the authorised third party. 
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Those ownership rules may be set up within the database. Automatic visibility 
rules may be created to allow V2, V3, V4 and V5 to exist. 
Respondent/Executor 1 should be able to view outstanding requests through 
V6. 

The Hub is then responsible for communication the order or request to the 
supplying party by whatever is the most appropriate means, also depending 
on internal rules. Normally, the hub will send normal mail to unknown 
suppliers, and will communicate electronically or by fax with known suppliers. 
At predefined times, the Hub will output a print file to an internal or external 
print facility where outbound mail is concerned. Otherwise it may send a fax 
via a fax server or an e-mail directly to the concerned supplier. Those 
communications are depicted as R8, R9 and R10 in the diagram. These are 
requests or orders being sent to Respondents/Executors 1-3. 

In one form of the invention, we will enclose a brochure explaining the system 
when we send our requests out. 

The respondents/executors will have a choice of how to respond. Where an 
action is undertaken, the response may be, for example, a scanned signature 
document where couriers are concerned. In the PMAR system it will be 
responses to questions. In the reference system it will be a reference. For 
casual airline staff, it may be the equivalent to a time sheet stating the dates 
and times of an encounter. The response may either contain information or 
serve as proof of execution acceptable to the system subscriber. In this form 
of the invention, Respond/Executors may respond live over the internet eg. 
S1, S2. They could also send a template e-mail within S1 and S2. If they opt 
to respond by normal mail or by fax, their communications will be s1, s2, and 
s3 which pass through the Document Processing Facility (Docproc). In the 
Docproc, their responses are processed and relevant data or images 
uploaded into the Hub (S5). The Document Processing Facility is also critical 
to our solution as it allows receipt of communication through any standard 
medium. The document processing facility may be an outsourced scanning 
bureau service. 

At the point of S1, S2 or S5, payment may automatically be triggered. Using 
s1 , s2, or s3; we will request the respondent to preface any response with a 
standard template that captures the required data and also serves as a 
taxation invoice for local taxation purposes. In S1 and S2, the tax invoice may 
be generated live online. If S1 and S2 occur by e-mail, a template e-mail must 
be used, but that e-mail need not go through the Document Processing 
Facility. Once the responses are processed, they will become visible to the 
requesting party, and a notification may be sent. The communications 
processed through the document processing centre may be homogenised for 
presentation to the requesting party through a standard interface. 

Once the response has been processed, as per agreed timetables, payment 
may be executed either directly by the system subscriber (P1 or P2) or via the 
Hub system through P3 and P4. By automating payments, we are able to 
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provide a consolidated report to the system subscriber rather than requiring to 
reconcile requests to invoices on a one by one basis. 

Payment may vary in accordance with service levels set. For instance, an 
additional fee may be payable depending on the time between request and 
response, or on the time between different events within the response or 
through a host of other methods. The system will capture those payments. 

Organisations requiring integration may have this facility through the use of 
XML or another generic facility. 
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UNIQUE FEATURES OF THE SYSTEM CLAIMED BY BESMAT 

1. The system can be provided by third parties offering an industry wide 
service, or hosted by individual entities. 

2. The entire request and response system is managed by an internet or 
web linked computer system to include a database or workflow system 
as the primary engine. 

3. The computer system has a web based graphical user interface 

4. The computer system has the facility to upload and convert documents 
from other formats such as postal and fax into the computerised 
system. 

5. In one form of the invention, access to the system is granted initially to 
nominated individuals under the umbrella of a large entity. 

6. In one form of the invention, those requesting individuals are able to 
generate requests for information or performance, such as requests for 
answers, requests for survey responses, requests for references, a 
request to undertake an informal parcel pick-up or otherwise. 

7. In one form of the invention, those requesting individuals generate 
these requests through our invention or load those requests into our 
invention through an alternative method. 

8. In one form of the invention, the interface which those individuals use 
to generate requests may be tailored for their employer, or for the 
purposes of the request, even if the provider of our invention operates 
a common facility. 

9. In one form of the invention, the requestors select the appropriate 
suppliers) for the information required, such as Medical Practitioners, 
referees or survey participants or they use an allocation 
engine/algorithm to allocate the request. 

10. The request is then forwarded to the appropriate supplier by the most 
efficient means dependent on available contact information. 

11. In one form of the invention, the requestor has the opportunity to 
append any relevant documents to their request, such as authorities; 
including hard copies, digital documents or scanned or faxed 
documents. 

12. In one form of the invention, if insufficient electronic address data or 
authorities are held, then the system also offers the opportunity to 
make that request to the supplier by fax or in writing. 

13. The requestor is able to create third party visibility access using rules 
initially constructed in the system, or using rules created on generating 
the request or at any other time in the contract process. For instance, 
in one form of the invention, a Life Insurance applicant's financial 
planner may have limited access to the process subject to entry of only 
a planner number; or an applicant for an employment position may 
need to have a usemame and password generated to create their 
access to the processing of their references. 

14. In one form of the invention, these access rules can be configured 
dependent on requirements. The system may also offer consolidated 
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viewing for, say, financial planners who may have many applicants with 
several requests outstanding to multiple general practioners. 

15. The requestor, and/or the entity to which the requestor belongs will 
have management reporting tools built into the system to allow them 
also to view the status of the requests they have generated. 

16. In one form of the invention, should a written communication be 
required to the supplier, where appropriate, templates may be sent to 
capture relevant contact information for future electronic information. 
Eg. accompanying the request may be a form to complete with e-mail 
addresses and fax numbers that can be used in the future. 



17. The capture of the information received may be limited to any level of 
users of the system: for instance the same address may be propagated 
to only a limited group of users or to a whole corporate or across the 
user base of the system. 

18. Accompanying any request may be attached the terms and conditions 
of the trade, including any reply related bonuses and fee schedules. 

19. In one form of the invention, the respondent will be able to submit their 
response by any method, such as internet, fax or post. Their response 
may, for example, be proof of execution such as a parcel slip; it may be 
a response such as a medical report or a reference, or it may be any 
other response to signal completion or partial completion of the 
contract. 

20. The system allows facilities to manage partial completion. 

21. In one form of the invention, a covering template will, be included for 
postal responses to allow that response to be most effectively 
processed on its return. 

22. In one form of the invention, The respondent will have the opportunity 
in their response to stipulate payment details. This might include a 
BSB Number and Account Number, or an address to which a cheque 
should be mailed. 

23. Responses submitted electronically will be availed to the relevant 
entity, team or individual in a format that may vary and to a timing that 
may vary. 

24. Responses submitted through other means will be uploaded into the 
system and availed for viewing to the relevant entity. For instance, a 
written response may be scanned into the system for viewing by the 
requesting individual or requesting entity. 

25. Those responses will be viewed electronically, although they may be 
printed or otherwise manipulated. 

26. The responses will be presented in a managed format for ease of use 
by the requestor. 

27. In one form of the invention, payment may be initiated in the 
background. 
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28. Where the response is not purely information, the system may still be 
used to manage requests and payment, including use of a ticket based 
system eg. couriers completing a job upload the signed delivery slip to 
trigger payment. 

29. In one form of the invention, the system will measure time from request 
to response and will have the facility to make time related bonus 
payments. 

30. In one form of the invention, the system will measure volume or 
characteristics and will have the facility to make characteristic related 
bonus payments eg. number of words, number of pages, quality 
characteristics etc. 

31 . In one form of the invention, the payment may follow predefined rules. 
In other forms, the payment amount may be defined by the supplier or 
by a combination of pre-defined rules and a supplier choice. 



32. In one form of the invention, the system will have the ability to allow the 
respondent to enter their own fee. For instance, a specialist may wish 
to enter their own labour charge which would be unknown to the life 
insurance company. 

33. Where appropriate, responses may also be configured to allow viewing 
by third parties. For instance, the Life Insurance may require pathology 
tests to be completed and may choose to avail those to the applicant's 
Medical Practitioner. 

34. In one form of the invention, various methods are used to homogenise 
multiple communication media for proof of supply or information 
fulfilment into electronic format, be that an attachment or live database 
data. 
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SYSTEM OPERATION 



SAMPLE PROCESS FOR PMAR REPORT (Figure 2) 

In this instance, a Customer makes an application. This is depicted by 
Consumer 2 or Consumer 3 in Figure 1. The PMAR process is currently not 
visible to intermediaries or financial planners. The Corporate Entity will 
determine if a PMAR check is required based on the data they hold. If a 
PMAR is required, the relevant person or team within the corporate entity will 
generate a request through the GUI interface with maximum available data 
such as medical practitioner name and address. The requestor will also create 
viewing rules - perhaps permitting the applicants financial planner to view the 
application (V2) or indeed the consumer (V1). In the case of the PMAR, the 
consumer and intermediary would be able to view progress, but not the 
content of the response. Once the request is processed, if the system knows 
that the medical practitioner is registered and has permitted electronic 
communication, they will be sent a notification to log on. When they log on, 
they will view all of their pending requests and will be able to respond online. 
If they have not registered, but a fax number is available, the medical 
practitioner may be sent a fax including the standard cover sheet. If no fax is 
available, they may be sent a welcome letter. If the practitioner is not 
registered, a special pincode will be sent, allowing them to register. Once 
registered, they will have the opportunity to respond live online, or to respond 
by fax or letter. Relevant data will be captured on the cover sheet if they 
respond by fax or letter; or will be captured live online. The moment their 
submission is received within the Hub, the practitioner may be paid based on 
data they have provided. If their document is faxed or sent, it will pass 
through the document processing facility which will capture the relevant data 
for input and will present an image of the response to the Hub for subsequent 
presentation to authorised viewers. A tax invoice will be created or finalised, 
and the response will be available to the Corporate Entity for completion of 
underwriting. 
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SAMPLE PROCESS FOR PARAMEDICAL OR PATHOLOGY REQUESTS 
(FIGURE 3) 

In this instance, tests should usually be requested by the intermediary 
(Consumer2/lntermediary in Figure 1). However, the corporate entity will be 
able to make the request if appropriate. The requestor will create the request 
as per the database. In this instance, the field of providers is more limited than 
the field of medical practitioners but still wide. If a corporate entity has a 
preferred supplier arrangement in place, then the principal value added by the 
system will be the electronic processing of invoices and payment. The Hub 
will allocate the request to a supplier as per pre-defined rules, overrideable by 
the requestor. If the provider is a bulk provider, such as a preferred supplier of 
paramedical and pathology services, then the requests may be uploaded in 
batch. If not, the responses may be provided online, or again via the 
Document Processing Centre. Responses may also be uploaded in bulk 
through systems integration. The rest of the process is consistent, although, 
for instance, viewing permission may be created for the applicants own 
personal doctor to see their blood test results. This would be an additional 
viewing relationship. 

SAMPLE PROCESS FOR EMPLOYMENT REFERENCE (FIGURE 4) 

In this instance, once a candidate for a vacant position is provisionally 
selected, their potential employer will enter the details of their nominated 
referees into the Hub system. The hub will then automatically communicate 
with the nominated referee through the most appropriate method, including 
offering incentives where appropriate. The referee will respond either directly 
to the Hub online using the same pre-assigned PIN code system, or will 
respond through the Document Processing Centre. They can then be paid of 
sums are payable. 

The advantages of the system to recruiters are numerous. For instance, the 
time spent processing references in their office will be diminished. Instead of 
being processed by the relevant consultant, they can be delegated to a 
person of lesser skills, and the time devoted will be reduced. In addition, 
positions will be filled significantly more quickly, leading to improved cash 
flow. 



SAMPLE PROCESS FOR TEMPORARY/CONTRACTOR STAFF 
MANAGEMENT 

In this instance, the request for performance of work by a temp or contractor 
and the relevant performance and payment is managed by the system. 

In the first instance, the relevant work request or roster is entered into the hub 
(although an abbreviated service may not require this stage of the process). 
This creates a requirement record, which is the first step in the control 
process. Although the roster may be entered, it may also be uploaded directly 
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from a resource management program via XML. The roster is then sent to the 
temp or contractor by their chosen communication method. The temp or 
contractor performs the work, or a portion of it, and prepares their timesheet. 
If a signature is required on the timesheet (placing the onus on a single 
authority to check for signatures), the document must be signed. If signatures 
are not required, then the onus will largely be on the cost centre owner to 
monitor reporting and possible, if desired, pre-authorise individual payments. 
The temp or contractor may then choose to either post their document, fax it 
or enter it live online. If they enter it online, they may or may not (subject to 
the security requirements of the employer) be required to also upload a 
scanned copy of their timesheet. If the document is send to the Document 
Processing Centre, then the document is OCR'd and uploaded automatically. 

Once the data has been uploaded, the reporting is available to the employer, 
who may be required to authorise payment. Otherwise, a nominated authority 
may be responsible for verifying signatures, or mere spot-checking of 
reporting may be sufficient. Payment is then initiated, and automatic reporting 
generated ongoing for taxation purposes. 
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SAMPLE DATABASE DATA FLOW DESCRIPTIONS 

PROCESS OF CREATING A PMAR REQUEST IN DATA TERMS 



1. Person Working for a Corporate logs-in. They are identified through 
tbIUsers which also gives them a Team through tbITeam so that some 
information may, depending on predetermined rules, be viewed team by 
team rather than person by person. A screen must exist to alter, delete or 
add users and teams. The control of viewability may require another few 
fields in tbIRequirements and use of the table tbIFunctionRights to 
determine whether a whole team or just the individual has viewing rights. 
The user works for a company in tbICompany. When that user logs on, to 
some extend their user interface will depend on the company they work 
for. 

2. That person then creates a request. The request can be mixed 
Paramed/Path and PMAR or just one. This example is about PMARs 
which are sent to the applicants GP. The User creates a requirement 
through tbIRequirements. That requirement is an overarching document 
which relates to the individual identified in tbIPatients. That may include 
details of their employer in tbIEmployers. (multiple requirements can exist 
for one patient). The request also contains questions for the doctor in 
tbIQuestions. The doctor can answer them in the Response field of 
tbIQuestions. At the same time, the user creates temporary viewing 
(tracking) rights in tbITempUserViewRights and tbITempUsers for either 
the planner or for the applicant. There may be a need to restrict viewing 
through reference to the function table if complex rules are involved. For 
instance, the applicant would not be expected to have access to their 
blood results. The user then enters the details of the Medical Practitioner 
concerned to be referred to in tbIMedPract. 

3. tbIMedPract has additional table tbIMedPractRank to identify the types 
of medical practitioner such as GP, Neurologist, Dermatologist, 
Endocrinologist, Haematologist, Oncologist etc, referred to by a foreign 
key field in tbIMedPract. This will be used to determine standard pricing 
set up in tbIPaymentStandards. 

4. The system will identify which communication media are available for that 
Medical Practitioner and if they have registered or not, and send the 
request to the Medical Practitioner through the appropriate media. This 
may include the export of a table to a mail facility. Status must be 
trackable at all times. If the Medical Practitioner is only reachable in 
writing, they will be sent documentation encouraging them to register for 
this service through the use of a pre-assigned 12 digit first time access 
number which then merely sets up a password for them and allows them 
to view all outstanding request. 

5. The Medical Practitioner may either enter the responses online directly 
into the tbIQuestions table or he/she may fax or send a normal document 
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which is uploaded by the document processing facility into tbIDocos. The 
Medical Practitioner also either enters their payment details directly into 
tbIBankAccounts or this information is keyed by the document 
processing facility into the same table based on fields in the standard form. 
If the doctor sends results, a cover sheet will be provided which contains 
standard fields for data entry, indexing and also functions as a tax invoice. 

6. The tax invoice, and the payment fields in the main table will suggest 
standard prices dependent on those contained in tbIPaymentStandards, 
which are unique to each corporate user. The medical practioner may alter 
the values on the fly if they deem themselves to be worth a greater 
amount. . 

7. When the document is uploaded or the data entry completed, payment is 
triggered automatically, along with any bonuses contained in tbIBonus. If 
done over the web, a tax invoice will be generated. 

8. Archiving must take place to a mirror set of tables once payment is made. 
In addition, reporting must be generated for the company users. 

PROCESS FOR PARAMEDS 

1. A paramedical or pathology request may be ordered by either a 
Company User from tblUsers or by a Financial Planner from 
tbIPIanners. 

2. The same requirement data is captured as for a PMAR. Visibility may 
be extended to the Financial Planner through tbl Requirements if the 
request is being made by a corporate user from tblUsers. Except in 
this instance, the details of which tests are required are entered into 
tbIPathTests. This table uses standard tests from the tbIBIoods table 
which has for instance, a row for LDL, one for MBA, one for Hep C and 
so on. A selected set of tests are created within that requirement, 
including a paramedical which will be a row item in tbIBIoods. 



3. Those tests are assigned to a pathology office. Either by default using 
pre-assigned rules per company eg on a preferred supplier basis, or by 
the User or Planner. That Path Office is in tbIPathOffice. The parent 
company is in tbIPathologists. For instance, the test may be assigned 
to an office in Sydney or Melbourne. This is necessary for billing 
purposes. 

4. That data is then forwarded to the Path Office for their viewing online, 
possibly with an e-mail alert. A batch download may be availed through 
systems integration. 

5. The pathologist takes the tests, and the results are either entered live 
online into tbIPathTests or in batch in the background to the same 
table. 
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6. A cue is sent to the User or The Team that is relevant as pre-defined. 
For instance, although a planner has requested the test, one company 
might prefer (as would AMP probably) that it is immediately viewable 
by the Underwriting Team. When viewed, the results should be 
displayed against the standard acceptable ranges from tbIStandards. 
This can vary from company to company, but allows very quick 
checking. The Blood Prices are also pre-assigned in tbIBIoodPrices 
for preferred supplier type agreements or they can vary. Payment can 
be immediate or deferred. 
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